-
-
Notifications
You must be signed in to change notification settings - Fork 213
feat: add branch-based versioning for PR AMI builds #1902
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
samrose
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great improvement
one suggestion that might help, given that each AMI should have a unique name could be something like this (doesn't have to be this exact solution, but some way to generate uniqueness each time an AMI is created)
diff --git a/.github/workflows/ami-release-nix.yml b/.github/workflows/ami-release-nix.yml
index 3bcddf6e..a1b2e8f5 100644
--- a/.github/workflows/ami-release-nix.yml
+++ b/.github/workflows/ami-release-nix.yml
@@ -76,7 +76,7 @@ jobs:
PG_VERSION="$(nix run nixpkgs#yq -- -r '.postgres_release["postgres'${{ matrix.postgres_version }}'"]' ansible/vars.yml)"
BRANCH_NAME="$(echo "${{ github.ref }}" | sed 's|refs/heads/||')"
if [[ "${{ github.event_name }}" == "workflow_dispatch" && "$BRANCH_NAME" != "develop" && "$BRANCH_NAME" != release/* ]]; then
- SUFFIX="${BRANCH_NAME//[^a-zA-Z0-9._-]/-}"
+ SUFFIX="${BRANCH_NAME//[^a-zA-Z0-9._-]/-}-${{ github.run_id }}"
PG_VERSION="${PG_VERSION}-${SUFFIX}"
echo "Added branch suffix to version: $SUFFIX"
fi
Example output:
- Branch: feat/pull-request-image-version
- Base version: 16.3
- First run (run_id: 1234567890): 16.3-feat-pull-request-image-version-1234567890
- Second run (run_id: 1234567891): 16.3-feat-pull-request-image-version-1234567891
The run_id is guaranteed unique by GitHub and never reused, so you'll never have AMI naming conflicts even with multiple iterations on the same branch. (for instance)
|
Indeed, your improvement also helps us to track down what workflow run created the image.
|
Manually create unique Postgres version names in branch often leads to version conflicts with the base branch versions. These conflicts force developers to deal with manual conflict resolution and unnecessary rebuilds. To address this, this change implement automatic branch-based versioning for AMI builds triggered via workflow_dispatch on non-develop and non-release branches. The branch name is sanitized and appended to the Postgres version string. Example: Branch 'multi-version-ext/pg-partman' produces postgres version 'multi-version-ext-pg-partman'
Display the published postgres AMI version using GitHub Actions `::notice` annotation.
Starting to lint GitHub Actions workflows with actionlint.
GitHub run_id is appended to the version suffix to ensure uniqueness. It also enables to track the AMI back to the specific workflow run that created it using url like: https://github.com/supabase/postgres/actions/runs/<run_id>
ff8639a to
38df152
Compare
|
rebased to bring in mirror fallback which fixes failing ubuntu package installs due to mirror sync issues. |
|
going to revert this one until we account for https://github.com/supabase/postgres/blob/develop/.github/workflows/publish-nix-pgupgrade-scripts.yml and https://github.com/supabase/postgres/blob/develop/.github/workflows/publish-nix-pgupgrade-bin-flake-version.yml integration into this approach |
* feat: add branch-based versioning for PR AMI builds Manually create unique Postgres version names in branch often leads to version conflicts with the base branch versions. These conflicts force developers to deal with manual conflict resolution and unnecessary rebuilds. To address this, this change implement automatic branch-based versioning for AMI builds triggered via workflow_dispatch on non-develop and non-release branches. The branch name is sanitized and appended to the Postgres version string. Example: Branch 'multi-version-ext/pg-partman' produces postgres version 'multi-version-ext-pg-partman' * feat: add notice message for published AMI version Display the published postgres AMI version using GitHub Actions `::notice` annotation. * feat: run actionlint on GitHub Actions workflows Starting to lint GitHub Actions workflows with actionlint. * fix: generate a unique AMI version GitHub run_id is appended to the version suffix to ensure uniqueness. It also enables to track the AMI back to the specific workflow run that created it using url like: https://github.com/supabase/postgres/actions/runs/<run_id>
* feat: add branch-based versioning for PR AMI builds Manually create unique Postgres version names in branch often leads to version conflicts with the base branch versions. These conflicts force developers to deal with manual conflict resolution and unnecessary rebuilds. To address this, this change implement automatic branch-based versioning for AMI builds triggered via workflow_dispatch on non-develop and non-release branches. The branch name is sanitized and appended to the Postgres version string. Example: Branch 'multi-version-ext/pg-partman' produces postgres version 'multi-version-ext-pg-partman' * feat: add notice message for published AMI version Display the published postgres AMI version using GitHub Actions `::notice` annotation. * feat: run actionlint on GitHub Actions workflows Starting to lint GitHub Actions workflows with actionlint. * fix: generate a unique AMI version GitHub run_id is appended to the version suffix to ensure uniqueness. It also enables to track the AMI back to the specific workflow run that created it using url like: https://github.com/supabase/postgres/actions/runs/<run_id>
Manually create unique Postgres version names in branch often leads to
version conflicts with the base branch versions. These conflicts force
developers to deal with manual conflict resolution and unnecessary
rebuilds.
To address this, this change implement automatic branch-based versioning
for AMI builds triggered via workflow_dispatch on non-develop and
non-release branches. The branch name is sanitized and appended to the
Postgres version string.
Example: Branch
multi-version-ext/pg-partmanproduces postgres version suffixmulti-version-ext-pg-partman